-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Add support for TIME literal values #3010
Conversation
Codecov Report
@@ Coverage Diff @@
## master #3010 +/- ##
==========================================
- Coverage 85.95% 85.94% -0.01%
==========================================
Files 291 291
Lines 52382 52420 +38
==========================================
+ Hits 45025 45054 +29
- Misses 7357 7366 +9
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
Thank you SO much for this! I struggled for a few days on this issue. Your help is very appreciated! |
cc19881
to
8062885
Compare
SQLDataType::Time => Ok(DataType::Time64(TimeUnit::Millisecond)), | ||
SQLDataType::Time => Ok(DataType::Time64(TimeUnit::Nanosecond)), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change constitutes a fix as Time64(Millisecond)
is invalid. Rather that switch to Time32(Millisecond)
, I moved to Time64(Nanosecond)
as PostgreSQL requires at least microsecond precision per the documentation. Given Nanosecond comes at no additional cost, it seems reasonable to support the increase in precision.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that is 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
thank you @stuartcarnie ! note that time64 cannot be compared yet as there's no implementation in the kernel. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great -- thanks @stuartcarnie and @avantgardnerio
SQLDataType::Time => Ok(DataType::Time64(TimeUnit::Millisecond)), | ||
SQLDataType::Time => Ok(DataType::Time64(TimeUnit::Nanosecond)), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that is 👍
Benchmark runs are scheduled for baseline = 49a3b00 and contender = 15a9a4b. 15a9a4b is a master commit associated with this PR. Results will be available as each benchmark for each run completes. |
This PR teaches DataFusion how to interpret
TIME
literals. These values are stored as nanoseconds from midnight using aTime64(Nanosecond)
.Which issue does this PR close?
Closes #2883.
Rationale for this change
I adjusted the precision of
TIME
tonanosecond
, which is different from the draft PR #2884 by @andygrove. The rationale for choosingNanosecond
is that PostgreSQLTIME
requires microsecond precision. Microsecond precision requires theTime64(_)
type, so it seems safe to increase the precision to Nanosecond with no additional memory requirements.What changes are included in this PR?
Add support for
TIME
literalsAre there any user-facing changes?
This PR teaches DataFusion about
TIME
literals and therefore documentation would need to be revised.